Applicability of Agile Methodology in Technology Migration Projects: A Thematic Overview
Pritam Kaushik, Basudev Datta
MBA Student (2018-20), Symbiosis Institute of Management Studies, Pune
*Corresponding Author E-mail: basudev.datta2020@sims.edu
ABSTRACT:
Ever since, inception of IT services on global level, lot of SDLC methodologies were developed to ensure proper balance between Time, Cost and Scope factors of the Projects. Over period of time, it was noticed that IT services using waterfall SDLC were gradually unable to deliver best requirements, despite having extensive experience in handling such large-scale IT projects. To overcome the shortcoming of the Waterfall SDLC model in early 2001, Agile SDLC methodology was introduced, which is even till today treated as de facto best industry standards of any IT projects across the globe as it successfully curtailed the demerits of earlier model such as dangers of traditional, front-end planning methods that often lead to downstream development pathologies. In this research paper, an attempt is made by the authors to understand how Agile SDLC methodology helps in improving efficacy of software development and various challenges faced during the development process. Limited research is done to highlight the efficacy of same across different variants of IT Projects. It is worthwhile to mentioned based on the past experiences of the authors that in case of Technology Migration IT Projects, bare implementation of Agile Methodology will not provide any addition advantage and success rate is extremely low. Authors has made an attempt to decipher the root causes which influences the efficacy of Agile SDLC methodology on Technology Migration Projects and suggest new SDLC methodology with list of KPIs to monitor the success rate of the project on real time basis.
KEYWORDS: Agile Methodology, Waterfall Methodology, Technology Migration Projects, KRA, CSF, KPI.
1. INTRODUCTION:
Before coming to Agile, let’s look at a brief on what exactly is a Technology migration Project. Migration from Legacy to new updated systems is one of the most consistent project forms both in IT or otherwise as due to the fast-changing global technology scenario everyone needs to keep up with the change to be relevant in the business. Migration projects can be software based, hardware based or a combination of these.
In IT, migration in general is the process of moving from one operating environment to using some other operating environment that is, generally an upgraded/better one. It can either be a hardware, software or a mix or both depending on the company’s Migration plan. The implementation plan can be either Big Bang, Phased, Parallel run or Rollout approach completely depending on the criticality/urgency of project and the feasibility, all of which needs to be planned initially. Now that we know what Migration project means, we will talk about various project Management methodologies, and for this paper we would concentrate on Agile methodology, its benefit over waterfall/traditional method and then we will check whether it’s the right approach/applicable in data migration projects.
It has been 18 years (February 2001) since the Agile Manifesto first gave us the principles that become the de facto standards of agile development methodologies, and since more than 15 years ago the agile movement started to impact the software development industry. So, can we assume that IT projects would have had a drastic turnaround in terms of project completion in right time and cost? Let us look at the IT projects health report. Among IT projects, failure rate corresponds heavily to project size. An IT project with a budget over $1M is 50% more likely to fail than one with a budget below $350,000. For such large IT projects, functionality issues and schedule overruns are the top two causes of failure at 22% and 28% respectively (Workamajig.com, 2019).
Fig 1: Success rate for different budget size (after Workamajig.com, 2019)
We have seen many such reports lately across the Globe which makes us think there is something wrong that even after having such methodologies the success rate of projects is too low.
2. TRADITIONAL PROJECT MANAGEMENT i.e. WATERFALL VS AGILE:
Ever since inception of IT industry across of the globe, 4 decades ago, there have been lot of development in the field of Software Development Life Cycle (SDLC) methodology to efficiently cater to the need of the client. Following are the SDLC methodologies adopted across IT industries as mentioned below (Cho, 2010);
a. Waterfall Methodology:
It is sequential model were-in the entire software development process is clearly bifurcated into 7 different pre-defined phases i.e. Feasibility ŕ Planning ŕ Design ŕ Build ŕ Test ŕ Production ŕ Support.
Fig 2: Process flow in Waterfall Methodology
b. Agile Methodology:
It also follows sequential approach as in case of waterfall methodology with added degree of flexibility in terms of accommodating the change requests as and when arises.
Fig 3: Process flow in Agile Methodology
However, survey clearly indicates that 60% of the IT companies would like to continue with Agile rather Traditional Waterfall Methodology keeping in view following 16 major differentiating factors between them as mentioned below (Laanto et. al., 2011, Lozo& Jovanovic, 2012, Sharma et al., 2012, Karamitsos et al., 2010, O’Sheedy, 2012 & Adjei &Rwakatiwana, 2009));
Table 1: Difference between Agile and Waterfall Methodology
|
S. No. |
Agile |
Waterfall |
|
1. |
It separates the project development lifecycle into sprints. |
Software development process is divided into distinct phases. |
|
2. |
It follows an incremental approach |
Waterfall methodology is a sequential design process. |
|
3. |
Agile methodology is known for its flexibility. |
Waterfall is a structured software development methodology so most times it can be quite rigid. |
|
4. |
Agile can be considered as a collection of many different projects. |
Software development will be completed as one single project. |
|
5. |
Agile is quite a flexible method which allows changes to be made in the project development requirements even if the initial planning has been completed. |
There is no scope of changing the requirements once the project development starts. |
|
6. |
Agile methodology, follow an iterative development approach because of this planning, development, prototyping and other software development phases may appear more than once. |
All the project development phases like designing, development, testing, etc. are completed once in the Waterfall model. |
|
7. |
Test plan is reviewed after each sprint |
The test plan is rarely discussed during the test phase. |
|
8. |
Agile development is a process in which the requirements are expected to change and evolve. |
The method is ideal for projects which have definite requirements and changes not at all expected. |
|
9. |
In Agile methodology, testing is performed concurrently with software development. |
In this methodology, the "Testing" phase comes after the "Build" phase |
|
10. |
Agile introduces a product mindset where the software product satisfies needs of its end customers and changes itself as per the customer's demands. |
This model shows a project mindset and places its focus completely on accomplishing the project. |
|
11. |
Agile methodology works exceptionally well with Time & Materials or non-fixed funding. It may increase stress in fixed-price scenarios. |
Reduces risk in the firm fixed price contracts by getting risk agreement at the beginning of the process. |
|
12. |
Prefers small but dedicated teams with a high degree of coordination and synchronization. |
Team coordination/synchronization is very limited. |
|
13. |
Products owner with team prepares requirements just about every day during a project. |
Business analysis prepares requirements before the beginning of the project. |
|
14. |
Test team can take part in the requirements change without problems. |
It is difficult for the test to initiate any change in requirements. |
|
15. |
Description of project details can be altered anytime during the SDLC process. |
Detail description needs to implement waterfall software development approach. |
|
16. |
The Agile Team members are interchangeable, as a result, they work faster. There is also no need for project managers because the projects are managed by the entire team |
In the waterfall method, the process is always straightforward so, project manager plays an essential role during every stage of SDLC. |
Based on the above cited different following interferences can be drawn as mentioned below;
Table 2: Parametric difference between Agile and Waterfall Methodology
|
Metric |
Waterfall |
Agile |
|
Planning Scale |
Long-term |
Short-term |
|
Distance between customer & developer |
Long |
Short |
|
Time between specification and implementation |
Long |
Short |
|
Time to discover problems |
Long |
Short |
|
Project schedule risk |
High |
Low |
|
Ability to respond quickly to change |
Low |
High |
Keeping in view the above-mentioned differentiating factors, most of IT companies have shifted from water fall to agile methodology as it highly efficient, provide competitive edge, gives positive collaboration from client side to faster and defect free software product deliver. Hence, IT companies implementing Agile SDLC should adopt to changes faster and get accustomed to new plans in a constantly developing and changing environment.
3. AGILE 12 PRINCIPLES:
Extensive research conducted by Sidhardhan, 2015 clearly highlights that the Agile Manifesto is based on 12 principles which are as mentioned below;
1. For any IT firm, the highest priority should be, to meet the high customer satisfaction index, at same time ensure continuous delivery of valuable software.
2. Agile SDLC provides competitive edge over traditional approaches due to it’s ability to accommodate change request from client side at any moment of time and same should be welcomed by development team.
3. Frequently deliver working software, from a few weeks to a few months, with a preference for the smaller timeframe.
4. Cross-functional team members i.e. Business people and developers must collaborate on day-to-day basis throughout the project.
5. Create proper work environment around the developers with special emphasis on motivational aspects such as timely support, trust worthiness etc.
6. Face to face communication channel between the team members must encouraged.
7. The primary measure of progress of the project is “Working Software”.
8. The sponsors, developers, and users should be able to maintain a constant pace throughout the project lifecycle as agile SDLC processes promote sustainable development.
9. Technical excellence and good design are of paramount importance and must be given continuous attention as same enhances agility.
10. Simplicity, the art of maximizing the amount of work not done is essential.
11. Promote self-organized team as best of the architectures, requirements, and designs emerge from those places.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
4. DIFFERENT AGILE TECHNIQUES:
a. AGILE SCRUM Methodology (Cervone, 2011, Cho, 2010, Parnas, 2006 and Schwaber, 2004):
1. SCRUM is considered as lightweight agile project management methodology in which incremental builds are delivered to the client in every two to three weeks' time.
2. It is usually implemented those projects were-in the frequency of change request is very high (i.e. dynamic requirement).
3. It fosters self-organizing and cross-functional team. There is no team leader, so the entire team addresses the issues or problems.
4. Quick response to change request.
5. High degree of collaboration is achieved through daily stand up meeting with a fixed role assigned to scrum master, product owner, and team members.
6. Post-sprint, a build is delivered to the client for their feedback through demonstration of the functionality.
7. Daily sprint meeting is conducted to review and feedback to decide future course of action for the project.
b. LEAN SOFTWARE DEVELOPMENT (Ahmad, Markkula &Oivo, 2013, Kniberg, 2009, Anderson, 2003):
1. Originally designed by Toyota Production System for adoption of lean manufacturing systems in automobile industries. On similar lines, Mary and Tom Poppendieck (2003) developed best practices for SDLC. It is iterative agile methodology that focuses mainly on providing value to the client and the effectiveness of the system that provides this value, called "Value Stream".
2. 7 principles of Lean software development are as mentioned below which closely associates with Toyota Production System’s Lean Manufacturing;
· Eliminate waste
· Amplify learning
· Decide as late as possible
· Deliver as fast as possible
· Empower the team
· Build integrity in
· Optimize the whole
3. It primarily focuses on eliminating waste by selecting & prioritizing the features to be added first among the list of valuable features needed for the system.
4. Due to a smaller number of intra-team work dependencies, lean methodology helps in efficient utilization of resources.
c. EXTREME PROGRAMMING (XP) (Beck, 2000):
It is considered as one of important SDLC methodologies developed in early 1990s which primarily used to improve the quality and response time to client’s change requests. It recommends utilization of time-tested best practices on software development projects of similar lines. Furthermore, this methodology can be successfully implemented in small scale projects as realization of face to face meeting post-completion of sprints
d. DYNAMIC SYSTEM DEVELOPMENT METHOD (DSDM):
Developed in 1994, it is one of agile SDLC methodology which works on the basic principle of MoSCoW prioritization i.e. Musts, Shoulds, Coulds, and Won’ts to meet the project constraints i.e. Time, Cost & Scope. Eight principles of DSDM are as mentioned below;
· Focus on the business need
· Deliver on time
· Collaborate
· Never compromise quality
· Build incrementally from firm foundations
· Develop iteratively
· Communicate continuously and clearly
· Demonstrate control
5. BASIC FLOW MODEL OF AGILE:
Unlike waterfall Agile is time bound incremental (smaller sprints) software development methodology that believes in continuous small deliveries to client and less documentation. This is basically achieved by breaking down the requirements into user stories and then prioritizing them and assigning them to each sprint.
Fig 4: Basic agile flow model (After www.sam-solutions.com)
6. BENEFITS OF AGILE:
Based on the testimonials of various eminent project managers of IT MNC majors, it can be clearly identified that following are the major benefits of using Agile SDLC over Traditional Waterfall SDLC are as mentioned below;
1. Reduced project cost overrun scenarios and probability of rework because of high degree of flexibility in the project plans (Kurup & Sidhardhan, 2015)
2. Agile SDLC extensively used iterative approach in the project which enables the development team to accommodate the change requests in the project specification without much need for any large scale re-work (Santos et. al., 2013).
3. It helps identification of potential risk and impending chances of any change request, which thereby helps the project manager in designing efficient project plan.
4. It drastically improves scope management & reduces the project overrun cost based on combination of factors such as improved abilities of development teams, proper requirement gathering, by enhancing the quality of the code development process and the timely delivery of project in shortest possible span.
5. Unlike, Infrastructure projects were-in the project manager has clear-cut visibility across the project in the planning phase itself. However, same doesn’t hold good in IT projects, as project visibility becomes more clearer during development phase, thereby making change request imminent. Hence, Agile SDLC places minimal emphasis on “project planning” & move the team directly into the development phase with short-term-less-rigorous plans in progressive elaboration mode, thereby saving resources in the planning phase of the project (Cervone, 2010).
6. It enables timely completion of the projects by eliminating scope for last minute re-work, by closing the gaps in the project plans, scope, requirement, and designs (Leybourne, 2009).
7. It facilitates “faster entry to market” through iteration and beta demonstration of the products.
8. It promotes continuous improvisation and sprints leading to faster delivery of projects (Sharma et. al., 2012).
9. Minimal documentation which eventually helps in early delivery of the project.
10. Improved customer satisfaction due to active and continuous involvement of stakeholders in the development and implementation of the project.
7. CRITICAL SUCCESS FACTORS FOR AGILE:
Extensive study was conducted by Jeffrey Verret (2018) &Gandomani&Nafchi (2015), to determine various critical success factors for on large-scale agile initiatives taken in IT based projects by various Project Managers, by searching several scientific journal databases which is as mentioned below;
|
S. No. |
CSF |
S. No. |
CSF |
|
1. |
Difficulties implementing agile |
6. |
Choosing and customizing agile methods |
|
· Project team’s inability to clearly understand agile requirements. · Lack of guidance from agile coaches. · Inadequate training. · Poor customization of Agile Methodology to meet organization’s need. |
· Use simpler approach. · Iterative nature of the agile deployments. · For ease of adaptation, Old methodology should be mapped to new one. |
||
|
2. |
Requirements gathering |
7. |
Mindset and Alignment |
|
· Improper requirement management. · Difficulties in creating estimates for user stories. · Improper transition planning from short to long term goals |
· Properly organizing team’s social functions. · Aligning Team’s goal with organization goals. |
||
|
3. |
Change Management constraints |
8. |
Management Support |
|
· Skepticism to adopt new working environment & style. · Unwillingness of senior management to abolish micromanagement tendencies. · Management’s attitude of maintaining status quo. |
· Maximum visibility of Management support. · Training of Management in Agile Methodology and it’s implementation strategy. |
||
|
4. |
Organization |
9. |
Training and Coaching |
|
· Lack of clarity in roles and responsibilities for middle managers and project managers. · Management’s willingness to maintains waterfall method planning expectations. · Difficulties in overcoming Internal silos. |
· Provide training to project team members on Agile Methodology Practices. · Regular guidance by Agile coaches. · Enable Learning by practice. |
||
|
5. |
Lack of buy-in |
10. |
Pilot Programs |
|
· Lack of or training. · Old ways of processing the requirements are still in use. |
Implements the learnings from training on pilot projects. Create lesson learnt database & to leverage the insights for wider rollouts. |
8. CHALLENGES WITH AGILE IMPLEMENTATION:
Till now we have established the benefits we can achieve from agile mode of Project Management. But can we confidently say that Agile is always applicable/right approach in every project? Let us see now various scenarios where Agile might not be that suitable:
1. Distributed teams:
The less documentation and continuous need to communication (Scrum) poses problems with distributed team scenario. Building the trust, cohesion among team members & managing people issues across all team members and having to establish effective communications becomes major challenges.
2. Project Scheduling:
As we have seen, agile methodology does not believe in waiting for the whole design specification to be made first and only concentrate on smaller requirements. This leads to difficulty in former planning in overall project duration. This in turn lead to bad resource planning as they come with cost associated with their time of use.
3. Scope Identification:
As we concentrate more on scope of Sprints, the management of Scope of whole project takes a toll. This most of the time leads to lot of delays and increased costs due to scope creep.
4. Documentation:
Most of the projects need heavy documentation either for version controlling or for making user manuals. Agile
methodology might not be useful or rather can be damaging to such projects as it believes in little or no documentation on the go. This also creates a lot of dependencies on the development team, which is not a favorable situation for the management.
5. Integration and overall Software Quality:
In large complex software development, having smaller sprints and sprint scopes can lead to overall degradation in code quality and takes a huge toll on integration testing especially when sprints are not in Sync. The sanity of the system as a whole decreases. This lead to lot of rework, when finally the stem Integration testing is done after all sprint completions. This is the major reason for cost and time overruns.
6. Training and development:
Due to continuous resource movement in larger projects, the official training of employees on Agile methodology takes a back seat as its not considered in sprint plans. Thus employees learn most of the things from colleagues just by observing and following them. This creates potential problem of not having best practice knowledge.
7. No formal metrics and Backlog Management:
Most of the projects lack backlog management tools either due to poor planning or cost saving approach. Also there are very few teams that build and regularly follow metrics to track project. E.g. Velocity, Burndown charts as specified in Scrum methodology.
9. TECHNOLOGY MIGRATION PROJECT BASIC FLOW DIAGRAM:
We have discussed above what Migration project can be. Like any other typical project, it also includes the stages shown below. It covers all the Aspects from Need identification, Process mapping for AS_IS and TO_BE stages, Design, Develop and Deployment, including all project management stages.
Fig 5: Process flow in Technology Migration Projects
10. PROBLEMS IN TECHNOLOGY MIGRATION PROJECTS:
Fig 6: Cause effect diagram of problems with tech migration
11. IS AGILE APPLICABLE:
When we talk about any migration project, first thing that differentiates them from any new project is the already existing technology processes that are being followed for BAU activities and other deliverables. There the complexity level involved in handling a migration project is much more compared to any fresh start project. Understanding the system integration across the project gains prime importance without which the whole TO_BE process might fail.
12. ALTERNATIVE SOLUTIONS: HYBRID MODEL:
As, we have seen various shortcomings of Agile in case of Technology Migration projects. Therefore, directly implementing PMO by using Agile Methodology won’t be a right approach. We have analysed and came with below mentioned KPIs which take advantage of both Agile and waterfall methodology i.e. A Hybrid Project Management Approach for Technology Migration Project.
Table 3: KPIs to evaluate the effectiveness of the Hybrid Project Management Approach for Technology Migration Project
|
KRA1 |
CSF2 |
KPI3 |
|
Scope Statement |
Prevent Scope Creep |
|
|
Change Request Management |
|
|
|
Appropriate Planning |
Resource Estimation |
|
|
System dependence mapping |
During Testing Phase;
|
|
|
Formation of CFT for project planning |
|
|
|
Activity identification and sequencing |
1. Critical Path Method 2. Project Evaluation and Review Technique |
|
|
Reduce Requirement Backlog |
|
|
|
Implement best practices for documentation |
Best practices for writing documentation: 1.Include A README file that contains (a) A brief description of the project (b) Installation instructions (c) A short example/tutorial 2. Allow issue tracker for others 3. Write an API documentation (a) What a function do (b) What the function's parameters or arguments are (c) What a function returns 4. Document your code 5. Apply coding conventions, such as file organization, comments, naming conventions, programming practices, etc. 6. Include information for contributors 7. Include citation information 8. Include licensing information 9. Link to your e-mail address at the end 10. List all the version of the files along with the major edits you did in each version |
|
|
Collaboration and Communication Management |
Efficient and Transparent Communication |
|
|
Establish Response Time (TAT) |
Turn Around time = Burst time + Waiting time
|
|
|
Resource Planning & Management |
Better utilization of resources |
|
|
Employee Motivation & Morale |
|
|
|
Reduction in employee attrition |
|
|
|
Improving Employee Statement |
|
|
|
Project Quality Management |
Implement Version Control |
|
|
Unit Testing |
|
|
|
Streamlining of processes |
|
|
|
Cost Benefit Analysis & Tracking the progress of the project |
Return on Investment (ROI) |
ROI = (Gain From Investment – Cost of Investment) / (Cost of Investment) |
|
Cost Performance Index (CPI) |
CPI = Earned Value / Actual Costs |
|
|
Schedule Performance Index (SPI) |
SPI = Earned Value (EV) / Planned Value (PV) |
|
|
Schedule Variance (SV) |
SV = EV – PV |
|
|
Cost Variance (CV) |
CV = EV – AC |
|
|
Expected at completion |
AC + (BAC-EV)/CPI
BAC = Budget at completion (when the project started) |
|
|
Customer Relationship Management |
Increased customer satisfaction score |
|
|
1KRA: Key Result Area, 2CSF: Critical Success Factors, 3KPI: Key Performance Indicators |
||
13. CONCLUSION:
In this paper we have analyzed and discussed our findings on the challenges in the adoption of Agile Methodology in technology migration projects. The identified challenges were mainly around Scope identification, documentation, Integration and dependency, distributed teams. This research has a few underlining limitations that present opportunities for further research which might be an empirical one. However, it would be important to verify our proposed model by implementation in any live project and if beneficial extend it to other forms of Projects. We have seen in the paper, there can be various forms of Technology migration; we would suggest further research in any particular Technology/System migration in the organization.Furthermore, we have concentrated more on the Scrum Methodology of agile but in the future,research studies can be done to form more hybrid models to improve the efficacy of Technology Migration Project Management.
14. ACKNOWLEDGMENTS:
IT project management is one of the key areas I had always wished to do research about, particularly since in 2017 when I led a 6-member team for the first time in my life in a migration project from Oracle environment to TalendData Integration. Now finally when I am here in my post-graduation I get the time and opportunity to do a detailed study and learn through the course of it. But as for every novice, research paper writing is challenging. I saw myself growing throughout the process not just in the topic at hand per-se but even at a personal level defying my own boundaries. My sincere gratitude towards my co-author of this paper Mr. Basudev Datta who has been my guide throughout for teaching the art of paper writing, and being my support system. Furthermore, I am grateful to my family for believing in me and supporting me in every decision.
15. REFERENCES:
1. Adjei, D., & Rwakatiwana, P. (2009). Application of traditional and agile project management in consulting: A case study of Price Waterhouse Coopers. Umea University. Retrieved from https://www.divaportal.org/smash/get/diva2:303565/FULLTEXT01.pdf.
2. Agile Approach by SAM Solutions, Retrieved from https://www.sam-solutions.com/blog/wp-content/uploads/2018/07/AGILE@2x.png
3. Ahmad, M. O., Markkula, J., &Oivo, M. (2013). Kanban in software development: A systematic literature review. 39th Euromicro Conference on Software Engineering and Advanced Applications, (September), pp. 9–16
4. Anderson D. (2003). Agile management for software engineering, applying the theory and constraints for business results. Prentice Hall, Upper Saddle River, NJ
5. Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Mass.: AddisonWesley.
6. Cervone, F. (2011). Understanding agile project management methods using Srum. International Digital Library Perspectives, 27(1), pp. 18- 22
7. Cho, J. J. (2010). An Exploratory Study on Issues and Challenges of Agile Software Development with Scrum. Issues in Information Systems, 9(2), p599.
8. Gandomani, T. & Nafchi, M. (2015), An empirically-developed framework for agile transition and adoption: A Grounded Theory approach. The Journal of Systems and Software, 107, pp. 204-219.
9. Jeffrey Verret (2018), Implementing Agile Methodology: Challenges and Best Practices, Applied Information Management Program, University of Oregon, pp. 1-70.
10. Karamitsos, I., Apostolopoulos, C., & Bugami, M. (2010). Benefits management process complements other projects management methodologies. Computer Science & Communications, 3(9), pp. 13- 21
11. Kniberg, H. (2009). Kanban vs Scrum – how to make the most of both, Retrieved from: www.crisp.se/file-uploads/Kanbanvs-Scrum.pdf.
12. Kurup, D., & Sidhardhan, S. (2015). Agile project management: Benefits and challenges. Academia. Retrieved from
https://www.academia.edu/19888935/Benefits_and_Challenges_of_Agile_Project_Management.
13. Leybourne, S. (2009). Improvisation and agile project management: A comparative consideration. International Journal of Managing Projects in Business, 2(4), pp. 519- 535
14. Lozo, G., & Jovanovic, S. (2012). A flexible hybrid method for IT project management. Journal of Emerging Trends in Computing and Information Sciences, 3(7), pp. 1027- 1036.
15. O’Sheedy, G. (2012). A study of agile project management methods used for IT implementation projects in small and medium-sized enterprises. Southern Cross University Library. Retrieved from http://epubs.scu.edu.au/cgi/viewcontent.cgi?article=1274&context=theses
16. Parnas, D. (2006). Agile methods and GSD: The wrong solution to an old but real problem. Communication of the ACM, 49(10), pp. 29-12
17. Project Management Statistics: 45 Stats You Can't Ignore. Retrieved from https://www.workamajig.com/blog/project-management-statistics
18. Schwaber, K. (2004). Agile project management with Scrum. Redmond, WA: Microsoft Press.
19. Sharma, S., Sarkar, D., & Gupta, D. (2012). Agile processes and methodologies: A conceptual study. International Journal of Computer Science and Engineering, 4(5), pp. 892- 898.
20. Sidhardhan, S. K. (2015), Running head: Agile Project Management-Benefits and Challenges, University of South Florida, pp. 11-21
21. Santos, M., Bermejo, P., & Tonelli, A. (2013). Improving the management of cost and scope in software projects using agile practices. International Journal of Computer Science & Information Technology, 5(1), pp. 47- 64.
Received on 06.10.2019 Modified on 19.11.2019
Accepted on 25.11.2019 © A&V Publications All right reserved
Asian Journal of Management. 2020; 11(1):97-106.
DOI: 10.5958/2321-5763.2020.00016.5